Can you create separate PRs for the expending of the record parsing and the bloodhound compatible output?

Can you create separate PRs for the expending of the record parsing and the bloodhound compatible output?

Certainly, I also remember talking about you, and you mentioned that you already have a tool for that called Foxhound. Is there any chance of getting snippets of it for reference

@B0TAxy are you targeting the CE or the legacy BloodHound?

The CE but I will say the branch is very outdated I will push the updates on Monday probably

@qmadev I’ve pushed the updated branch. It’s still missing a few objects (domains, OUs, groups, and GPOs), but I’d appreciate your early impressions on the current progress.

Lgtm!

Just an idea for the future. It should be possible to get things like local groups and sessions as well. Acquire is already able to collect sessions with the volatile profile and the local groups are somewhere in the registry iirc. All we would have to do is parse the data correctly. So instead of relying on DCs only, you could build a bigger picture if you have the correct data.

Attackers already do this type of stuff. Looking the the CS-Situational-Awareness-BOF for example. In particular netloggedon2 and netLocalGroupListMembers2

Lgtm!

Just an idea for the future. It should be possible to get things like local groups and sessions as well. Acquire is already able to collect sessions with the volatile profile and the local groups are somewhere in the registry iirc. All we would have to do is parse the data correctly. So instead of relying on DCs only, you could build a bigger picture if you have the correct data.

Attackers already do this type of stuff. Looking the the CS-Situational-Awareness-BOF for example. In particular netloggedon2 and netLocalGroupListMembers2

Agreed, you’re 100% correct—integrating those volatile sessions and registry-based local groups would definitely provide that 'bigger picture' attackers look for.

I actually included a comment in the code regarding this for the future. Since that logic is a bit of a departure from the current DC-focused work, I think it’s best handled as a separate enhancement to keep this PR clean.

However, let me know if you’d prefer to see it tackled here.